After Lapsus$, How to protect your SSO from vendor and contractor compromise

Rob MacDonald: My name's Rob MacDonald. I'm going to be your MC today. For those of you that joined our last webinar, my face might be a little bit familiar, but today we're going to talk about how to protect your single sign-on from vendor and contractor compromise. Before we jump into that, though, there's a couple of housekeeping items that I just like to quickly jump through. Mike, do you want to move that? There we go. We have our next webinars already set up and ready to go for next month.

That's going to be around MFA tried to fix passwords but how do we fix MFA? Which is a great title, I think there's going to be lots of great discussions around that. That's going to be September 22nd, same time as this one. If you're interested in that, that's on our website. You can register, seats are always limited. If you want to see that, register for it now. Make sure you guarantee yourself a spot.

Then after that, what we got after that? That's right, if you want to try the BlockID Experience, you can go to our website and give that a go. Go to www.1kosmos.com/demo. You will be asked to download the app, scan a QR code, enroll, and set up your biometrics and then use it to authenticate. If you want to see how the process works at a very high level, that's a great way of going about doing that.

Just another side plug, tomorrow we also have an IBA Friday where myself and the VP of Product Management jumps on to LinkedIn live around two o'clock Eastern, quarter after 2:00 Eastern. We're going to be talking all things security. It's about 15 minutes, it's not too long. I think tomorrow we're going to talk [inaudible 00:01:49] I believe. On that note, I think it's time to jump in.

Today's speakers. We have Mike Engle, who's the co-founder and CSO here at 1Kosmos. John Bogdan from who's a IAM Expert from iC Consult. Mike, why don't you introduce yourself and tell the audience a little bit about who you are and what you do here.

Mike Engle: Yes, it's great to be here. Thanks for everybody for joining. I'm co-founder here and had a strategy working on our go-to market mechanisms. Background in InfoSec, I've built a program, the InfoSec program at Lehman Brothers way back in the day. After they went bankrupt, I transitioned into the venture back startup world. I've done a few of these things. Built a couple of fun companies.

I also run an identity-focused venture capital fund called 1414 Ventures. We keep an eye on all things identity over there. It's a seed stage fund. All identity all the time for me. It's great to be here. Thanks, Robert.

Rob MacDonald: Thanks, Mike. John, why don't you tell us a little bit about yourself?

John Bogdan: I'm John Bogdan. As you can see, I work for iC Consult Group. I've been involved in IT since the mid '90s and in directory services and authentication since around 2000. Focusing now for the last, well, I'd say five, six years on Okta.

Rob MacDonald: Pretty good, excellent. Welcome, John, thanks for being here. Mike, you as well on that note, I think it's time. Mike, I'll hand this over to you and get started.

Mike Engle: Thank you. As the title of the webinar indicates, we're going to talk a lot about how to properly authenticate. The way we've been doing it forever is horribly broken. We're seeing pretty much weekly bypasses of existing controls. There's some real doozies that came out in the past couple of months. I just want to touch on them quickly, including the two that happened in the past 10 days or so.

Going back a few months, we had MailChimp that was bypassed and related to that, you see about Twilio here in just a minute, but they basically let somebody get access to that second factor. You're using a third party service to send codes, there's a real vector there. Phishing was involved and so forth. Similar to that was the Robinhood breach, where they socially engineered a customer support employee by the phone.

If your customer service people get compromised, it's pretty much game over for a lot of different vectors. That resulted in the emails for about 5 million people getting exposed. I think a lot of people had that pucker moments when Okta got hacked a couple of months back as well. We're going to talk specifically about some ways we can strengthen the authentication into Okta and other SSO systems today because we have the SSO expert on the line with us here today and John.

I think a lot of people know what happened on this one, but again, it was a customer support employee that got compromised and the bad guys got in, and got access to different parts of their downstream infrastructure. Some of the newer ones that came out, Cisco, I'm going to detail this in the next slide. John, I think you're pretty familiar with this one and what happened there. You want to comment on this one briefly?

John Bogdan: This one was a combination of a phishing attack and what many people called MFA fatigue. They received text messages and the employees, when the hacker got a list of their employees phone numbers and using that and the SMS phishing, they were able to obtain their Google account. Now, using their Google account. They got access to their key ring.

Basically, used that and saw that many of the folks had put in their VPN passwords in their keyword. Using that, they were able then to go in and even though they had dual as the second factor, everyone's familiar with trying to crash an apartment building. What you do is you hit all the numbers and you keep hitting the numbers until somebody responds. What they did was they kept doing push notifications.

Eventually, some folks responded either they meant to hit no, or probably they thought, "I'm working online right now. I don't know why I'm getting another notification, maybe my network picked up." They went ahead and let the folks in. As a result of that Mimikatz and some other malware [inaudible 00:06:29] network.

Mike Engle: I think let's just run through this one quickly since you know it pretty well. I didn't realize when it first happened that it was linked to the employee's personal Google account. Like you mentioned, Keyring was a key part of this hack, so imagine if I go get a list of 100,000 employees and their phone number, super easy to do. Then haul them up and get access to that personal Gmail account or whatever it is that's on their machine.

Eventually, you'll get through to somebody, somebody will make a mistake. Now, I have access to your johnbogdan@gmail.com. Now, as you pointed out, this Google account has other passwords inside of it. Now, you're starting to crack open of the equivalent of the password vault. Of course, now what can you do? You can get into the first layer of authentication into the VPN, username password.

It's right there stored in Keychain right now. All you have to do is send them thousands and thousands of messages or just be strategic about it. I know personally when I'm typing on my phone, the little popups that are happening at the top get in my way all the time. This morning I just took a picture of this because I was like, "Why is Waze asking me for permission to use my GPS? It must have popped up. I said, "No, and didn't know it."

I could have easily said yes to something. This is really a weak link in 2FA and we're going to talk specifically about this today. Once you hit yes by accident, bang you're in and off to the races. You did a great job of breaking that down and I made the pretty icon.

John Bogdan: There's one other aspect I wanted to bring up on that too. This is what I've seen with a lot of companies. Folks will call into their help center and get their second factor authenticated. They do it right there on the spot. They don't call back to know numbers or anything like that. Even if they didn't want to do the push notification at writ large, they could have called the help desk and gotten them to push out a new authenticator, which they could have downloaded themselves, and thereby granting access.

Ripping users away from their knowledge or factors is easy and usually get a few people to do that. Even to the point where companies aren't hardening their access to securing their second factors.

Mike Engle: Exactly right. Then, lastly is the signal exposure that happened a couple days ago. This happened because they used the phone number for verification and they used Twilio to send that message, so they hacked Twilio and got access to, I think they said about 1,900 Twilio customers. Definitely, one signal customer was compromised.

I know signals working to move to more of a username and less of the phone related model, but that's what's happening. There's a couple things we can do about it.

John Bogdan: Mike?

Mike Engle: Yeah.

John Bogdan: The only thing I wanted to say about the Twilio, their response was to go back and do more security training for their employees, telling them not to respond to phishing emails. We've been doing that I just wanted them to scroll. We've been doing that for a decade now. Einstein says, "When you try to do something like different outcomes, it's a definition of insanity."

We've got to get past there's always going to be one or two or several people that will always respond to fishing attacks. The point is we've got to harden ourselves with real identity proofing and real authentication.

Mike Engle: Exactly right. This is a very simple litmus test and then we're going to have a polling question right after this that Maureen's going to pop up. Can you give your second factor to somebody else? For most authentications out there it's yes. For example, if I can at the time that I get my code and I bind it, I can give it to somebody else.

If that's the answers, yes they're going to tie this into the foundations of Zero Trust here, which is what we need to strengthen the identity framework that we've all put into our organizations. Maureen, if you would pop up the first question, I'm going to say, I don't want to give away my answer.

Rob McDonald: While that's happening, just so everybody knows if you do want to ask questions as we're going through today, there is a section where you can ask questions. We have people of behind the scenes answering questions as we go through today. Then, we'll also take some questions at the end. If you do have questions, feel free to enter them into the chat and we will reply.

Mike Engle: Very good. Thanks, Robert. That was an easy one. We had no surprises there, that was a loaded question. Let's talk zero trust just for a second. Zero trust means a million things to a million different people, but at the foundation of it is identity, it's undeniable. I was at the Gartner Security Summit a couple months back, and this was a major theme that identity being foundational.

Even if you're already relatively mature, you have to keep innovating on the identity side. Then, everything else becomes easier if who's accessing your devices or your networks or your apps and APIs, it makes the security of them much easier and you'll still do compartmentalization and all those things. It's a multi-year program and really an ongoing process, not just about a product. John, I'm sure iC consult is pretty heavily involved in a lot of zero trust efforts, yes?

John Bogdan: Right. The stuff that you outline, a lot of the companies like Okta are doing it right out of the box, as far as devices and network, for instance. You can now with all of the new release of OIE, you can either have managed devices where your MDM solution pushes out the Okta Verify, which is a good way of segregating who has access to that authenticator, as well as what network, making sure that if the person's coming from the corporate land.

You can give them a little bit less security on that one. Even though, that's becoming more and more harder now with the remote workforce. There's some things that Okta's doing out of the box, but the key thing here is identity. That's still the whole identity proofing and the authenticator behind it is it's still missing. This is things we're talking about today.

Mike Engle: Great segue way. Two standards that really nail down identity, there's three certifications or there's many certifications, but the two that I wanted to touch on here today with you John is the first is how do you prove who you are remotely? This is missing from nearly every authentication stack. The identity standard that was put out by the NIST, U.S. government standards body is NIST-800-63-3. The first part of that is identity assurance.

Are you sure that this is John or are you sure that this is Robert? Typically, involves two sources of truth about you and that could be a driver's license or some type of database in check, et cetera. The key here is real biometrics. You cannot prove who somebody is without looking them in the face with technology, obviously, but there is even a human element that can be done and matching that to whatever the source of truth is about them.

It's the same thing that happens when you go to the TSA, go try to go through a checkpoint, hold up your credential, look at your face and go through, and we can do that digitally now. Then, once you have proven who you are, you need to use that proof over and over again. Here you're leveraging the second part of the standard 800-63-3B with FIDO. I'm sure almost everybody in the audience is familiar with FIDO authentication. John, are you seeing more adoption of these things?

John Bogdan: Absolutely. The IAL is I think a key piece. There's three levels to that. One is just basically a self-authenticator. Level two is, goes something like this, you mentioned a few passports or a good slide. You mentioned driver's license and password or passport. What you do in step one, you enter all your information, birthday, email, address, name, all that kind of stuff, as well as then your driver's license and passport.

What happens is that the at level two is each of those things are verified in the sense that does what I entered personally match. What is out there publicly available or in other license bureaus. When I do my driver's license, I upload my driver's license it then takes the QR code, and does that QR code match the plain tech? Does it check the whole stars, all the layout of it to make sure that it's not a forgery until you get to level three, then it matches to your face.

Once the identity of all the submitted documents have been validated, then you get to the point where you're level three is there's a live look on the person does it match what's on the driver's license in the passport. Then, whatever's entered on the phone code get sent to you onto your phone, to which you finally get the authenticator. That's the marrying of that person to the authenticated. It's fairly rigorous.

The good news about it is even with level two, all that can be done remotely, which is a key aspect of being able to use this in a large segment of our population. It's only when you get to level three that you have to be personally onsite in order to do that level of verification, but that's typically for DOD that type of thing, but you can get quite a rigorous authentication done even at either remotely.

Mike Engle: We've come up with a term for putting these things together, the identity plus the authentication we call it identity-based authentication, very clever term. What's key here is making sure that this stuff is done and to do that, there's several certifying bodies. Kantara is the nonprofit that globally proves that you onboard identities properly. They'll put you through testing.

There's only a handful of companies that have done this to get to the highest level that they certify for, which is IAL2. Then you just need to make sure you're authenticators are FIDO certified as well. There's a FIDO2 server spec and there's authentication specific token authentication specifications as well for the client side. Then lastly, if you are using real biometrics, you need to have those biometric certified for accuracy, false acceptance, false rejection.

Things like decisioning bias are really important these days. These certifying bodies go together, there's a couple others out there as well. Maureen, I'm going to have you pop up the second question. I don't remember what we're doing here, but I'm sure it's as exciting as the first one. This question is, I've heard from some of our clients in the FS-ISAC, which is the Financial Services Information Sharing Consortium. That there's a growing problem.

Actually, this has been announced by the FBI recently, where the people you hire, aren't who they say they are. Somebody you hire gives their credential on day one to somebody else because they work cheaper. We have a lot of people that say they're not very confident in who's actually behind the authentication. Somebody's pressing yes on the phone, do I really know it's them? Curious what a couple of you think about the strength of your authentication or your knowledge of really who they really are.

We'll see where this one lands here in just a minute, but that was the purpose of this question here. Good, right across the board. We're somewhat confident and you trust your employees for the most part. They've been working for you for a while or you do vetting. They seem like good people, but you have a lot of contractors, there's a lot of transient people and I've heard stories of people in COVID working at five different companies at the same time.

It's a mixed blessing. Thanks for that, Maureen. We'll share those results afterwards in a follow-up message. We addressed the standards around identity. If you really think about what is identity, it means a million things to a million people. It could be, I have these and interests or live in this home or have these friends or whatever. In a digital perspective, it's who you prove you are remotely.

That can be your corporate identity, your citizen identity, even how your bank identifies you. Again, you have these standards matched up combined with then how you use it. The reason I'm showing this is because to verify these two things, there's two things that we need that we couldn't really do that well five or six years ago. That is the widespread use of a private key. It was a cryptographic key, which is what FIDO uses.

We've been using in lots of authentication scenarios for a long time and biometrics to prove that you are the person that enrolled. Now, ever since the advent of the iPhone 5, we have billions of devices. Of course, the Androids that came out around the same time, billions of devices that we can now keep a key in. Of course, you can still use external keys and smart cards and all that.

I have a 12 megapixel camera here, which can scan my face or a very high quality microphone that can listen to my voice. These are now enablers and they're getting more and more trusted. How often do you use biometrics to get into some type of system John or your clients?

John Bogdan: Quite often, yeah.

Mike Engle: We unlock our phones a thousand times.

John Bogdan: I think you'll show the LiveID and I hope folks will see how superior that is. It's just the Apple face recognition or Google face recognition.

Mike Engle: We're actually jumping to some live demos here in just a second after just one more slide. How do you fit these pieces into your infrastructure? I want to have strong certificate-based authentication match with biometrics and they are missing case at the end of the day, we want to prove who the users are. We can do a TouchID, FaceID or what we're going to show you something called LiveID, which is a real biometric.

That cryptographic proof will let you get into then your downstream systems. What are some of the common federated authentication protocols John, that you would employ or your company employs in these systems? Your SAMLs and those types of things.

John Bogdan: Exactly, SAML or OIDC, and as we'll see the integration between Okta and some of the verifiers like ID being the authenticator follows those same standards.

Mike Engle: Cryptography can verify the life of a coin, a Bitcoin for every time it changed hands. Why can't we prove who accessed our systems? When you go look inside your Windows user logs or Unix logs, whatever, it says J. Smith, is there a cryptographic proof that the same J. Smith got in is the same J. Smith that registered six months ago? I mean cryptographic proof, not just a log entry, and that is the other half system.

You should be able to go into your logs, click on it, and say, "Yeah, I've got the digital chain of trust that says, this is the same person that enrolled on day one in my organization. That is our definition of zero trust when it comes to identity it must answer who with authority. Just a simple way to think about it. I find that these two functions here in the middle are missing from most IAM stacks.

We'll jump into some live demos here, but first we just have to torture some people with one more polling question. Maureen, if you want to pop that one up.

John Bogdan: One more point on the IT governance. I was going to say one more point in IT, governance a lot of that data collection can be done when the employee gets hired. When you have to submit your passport or your driver's license and social, not that we're capturing social, but when you're submitting at that time, that can be validated as well.

Mike Engle: Exactly. Start the journey right on day one. Prove their identity and then inject that into your IGA system, that's a great point. Here, have you ever used a real scan of your face not TouchID or FaceID to get into a system? The problem with TouchID and FaceID is you can have four faces or thumbs registered on your phone and you don't prove whose thumb or face it is. My wife can unlock my phone and launch my trading application or whatever it is.

It doesn't prove identity. We'll see how this one shakes out. Go ahead, Maureen. 50/50, that's really interesting. I didn't expect it to be that high. Let's show how some of this stuff works. We're going to go through a strong identity onboarding that gets up the NIST, Identity Assurance Level two and here we go. We're going to start by just launching an experience with the user. This can be done in an app, via SDKs that go into an existing app, or even a 100% on a web channel just for the browser and using different types of cameras.

When the experience is launched that's where you generate a private key transparent to the user. Sometimes we'll use a pin, which is just one way to protect the vault, your identity wallet. We also use device biometrics. The stuff that's built in that we use every day. Now, let's enroll real biometrics. This is a live selfie. We call this LiveID and that's a certified biometric and that's it. It took about 30 seconds to enroll four factors for there, really.

Private key has been installed, public key went on the server, a pin, not use that often, but it could be handy. TouchID, FaceID, a decent biometric and LiveID. An incredible biometric right now. What do you do with it? I hadn't linked my identity anywhere yet. In this example, let's scan a government credential. Again, this takes a couple seconds. It automatically snaps. It's verified in real time.

Hundreds of fraud checks are done on these documents in real time. The data's encrypted and with the user's private key, it never leaves their possession until you ask for it. That's a key enabler, no pun intended, but where the data is only transmitted to the requesting party after consent, consent-based identity management. Lastly, let's put a second credential in. This is what it takes to get to a high level of missed assurance.

We'll do the scanning and this time you can actually read the NFC chip, which gives you a digitally signed credential from the Department of State or the issuing authority, high res photo, and all this data is triangulated. First name, last name matched, dates of birth matched photos matched. That is a high friction, but high level of assurance. Anytime I go to use this, now I have proof of who I am. John, I don't know, I didn't hear any oohs and ahhs, but it's pretty cool, right?

John Bogdan: It is and the thing that's nice about it is people can be nervous. I'm uploading all my personal information. The credential security provider, if you look at the NIST standard it basically breaks that segment off that verifies your identity. That information doesn't get passed to anyone unless you're called for it and you give the permission to pass that.

Mike Engle: That's exactly right. We saw a huge PR mess with the IRS a couple months ago where an identity provider, a private company was doing the identity onboarding. There was some question as to where and how that identity was being stored and used, and for what purpose. It's really important to have these privacy policies and really encryption and privacy by design factors.

Then, you do this, but you shouldn't have to do it more than once. Imagine if you had to go to the DMV every time to use your driver's license, that's what we have to do today every time we sign up for a new banking or DeFi or other type service. It's crazy. Then, third is that the biometric and the process certified properly. Decisioning bias is a huge deal. If you train your system on a certain class or type of people it'll end up excluding the ones that were in trained properly.

We have some amazing stats on how this is progressing and trending and organizations like the GSAlogin.gov have entire working groups around this. Of course, you have to support a global population and inclusion and identity resilience in those types of things. We've scanned an identity, let's show you how you could use it to onboard. I'm a new iC Consult employee or one of my customers. How do I inject myself into that organization?

Imagine I just onboarded my documents like you saw took me about three minutes, verified high level of assurance. It's time to transmit my data to Workday or to SalePoint or Saviant, or whatever it would be. This is the process. You're engaging user-initiated action, not a push message. Proving that it's the same person that's scanned the driver's license in the first place. Data is decrypted out of my wallet and sent to the requesting party.

There's all the info that was requested that is sent over because you need to provide it anyway for I-9 tax purposes to prove that you're a citizen of that country whatever it would be. John, I know you have a big IGA practice, hopefully we're seeing more and more of this get adopted across some of your clients, right?

John Bogdan: It's slowly getting there. I think the need for when they see what can be done right out of the get go, I think more and more are getting into on this.

Mike Engle: Now, this is a recording that John made for us since he's the Okta expert here. John, talk a little bit about how regular Okta authentication is done and what we demonstrated together here in the system that we set up together. A normal Okta experience versus where we're going here.

John Bogdan: Basically, the Okta allows you using Okta Verify you load it on your desktop now or on your phone. Most folks use it as a push notification and you can leverage the base ID. It's not necessarily required or in some cases they'll put a number on there and it has to match the number that the website provides. There's some level of authentication to that tied to that authenticator.

Like I mentioned before, particularly it's the case where someone grabs the username and password either from dark websites or from phishing attacks, they can basically call the help desk and get themselves a new authenticator and tie that to the account. Therefore, you can bypass all the security to handle that. What the LiveID verifier does is you mentioned that private key, that's gone through a strong identity proofing process to actually get that key.

It's not as easy to get it's just a regular Okta Verify authenticator. What you'll see here, the process is that 1Kosmos was used as the verifier. It's basically set up as the IDP here. There's application from Kosmos doing an inbound so that the assertions can be sent and they're signed and Okta accepts and understands that signature. If you can roll the tape, you'll see basically the process by which this is a dev site that I have.

It recognized me that, "This person uses the 1Kosmos as the verifier in this process." Now, I basically go and I click on log in with BlockID. My BlockID comes up. I scan the QR code that goes up there. Again, it's not push notification. We showed that push, not always that secure to do that. It's me engaging with the website here.

Mike Engle: Impressive.

John Bogdan: I think what was missing was the LiveID. The thing I like about the LiveID is it prompts you for a 360 view of yourself, turn the right turn to the left, and it verifies that it's a live person doing this because you don't know what's going to ask you and when, it varies. Each time I'm in there, sometimes it asks me to blink my eyes. Sometimes it asks me to smile and usually I have a different timing as far as when I'm using to do these things.

Mike Engle: That's right. That's called active liveness. There's two options and you can do active liveness, which is very difficult to do what they call presentation attacks, where somebody's holding up a mask or something. It's hard to make a mask blink at that right time, but there's also passive liveness, and we're seeing more and more of that. We have that as an option in the product, where you just got to glance in front of it quickly, and they're getting better and better, that's a better user experience, but not quite as secure.

Again, it's always about friction versus the benefit and the risk tolerance that you have. Thanks so much for doing that demo, John. It does picture worth a thousand words on that. I'm just going to fast forward into one other environment outside of Okta. This is a Windows' workstation. Imagine many of us have used Windows, hello, but it comes with a lot of challenges, you can't do it on domain controllers or virtual environments.

They only support certain hardware. Again, it's a device biometric. Anybody could be enrolled. It doesn't prove identity. What we've done here is integrated LiveID into Windows authentication. Then you wouldn't want to do that every time you unlock. I don't know about your workstations, John, but I have mine locking every 15 minutes, you don't want to walk away from a machine. If you had to do that heavy experience every time it's too much. Do LiveID maybe once a week or on some type of risk-based whatever your tolerance is.

Then do either TouchID, FaceID, or even your Apple Watch. Check this out, we'll authenticate into the workstation again, user initiated, not susceptible to push attacks. Here's a very strong cryptographic proof of identity authentication, and you're staring at the desktop. Even though, there's a lot of friction there, it's an amazing experience compared to a username and password, which has 10 times more friction and is very weak. Now, machine locks after 15 minutes or I lock it manually as you see here.

On second touch, let's lower the shields a little bit and just allow TouchID or FaceID. In this example, your watch is strongly bound to your phone. You unlock the machine, you'll see the watch here gets a push message you hit approve, and the machine is unlocked. Again, amazing user experience. These are all configurable depending on how far you want to go with different types of authentication. Sign me up for that every time, because once you start doing it, it's hard to go back.

A couple things to think about. I'd love your thoughts on, John. When you've been doing IAM for a long time before SSO was really a thing you've been working with identities and accounts, SSO came along, and now you're protecting 200 downstream systems with one authentication process. I'm wondering, SSO is great because instead of having 200 usernames and passwords, you have one, but are we putting all the keys to the kingdom in one SSO gateway?

If that SSO gateway, first of all, is in super locked down, if you get the golden SAML type attacks are now a thing, but also if you're not really proven identity at that gateway, then what happens here? I think we're going to see more of this. What are your thoughts?

John Bogdan: We're going to always move in the direction of what is to make the user experience less frictionless or more frictionless. That's where the whole thing with single sign-on come on. There's more and more adoption of that in a lot of companies, whether OIDC, SAML, whatever the case may be, that's always going to be the case.

Like you said, you want that first entry into the gate to be hardened. Think of it as a nightclub. You want that bouncer in the front gate to be very discerning and very powerful. Once you're in the club, you can go in any room you want, but you need to be able to verify who you are and that has to be guarded.

Mike Engle: Exactly right. We're seeing policy based step up, you're all authenticated, but now you're going to super secret system over here. Let's just ask them for another biometric check or a real biometric as well. Of course a bunch of ways you could ping them. Then we talked about this in the polling question, do you think your clients will start to use real biometric someday to prove identity?

There's really no right answer to this yet, but wondering what your thoughts are on this job.

John Bogdan: Yeah, I do think so, as long as users are guaranteed at a level of privacy. The LiveID, all that kind of stuff is basically interacting with you and the authenticator. What I mentioned before, as far as submitting your public documents and that's held that a credential service provider, that issues that's determines who you are and goes through the process of issuing that authenticator. That's one party. Once you get that authenticator, you can use all different parties.

You're always aware of what attributes are being passed by the credential service provider you're able to ask for that. If anybody needs anything more, most of the applications are fairly anonymous, they don't really need to know your name or anything. They just want to know that this is a valid user of this system. They don't care about your birthday and all that kind of stuff.

Some cases they want to might know, "Is this person at least over 50?" If you agree to that, the correct service provider will send that information in that attribute to the verifier, either to the verifier or directly to the target system called the relying party. Again, you have control over what kind of information is being passed.

Mike Engle: Then last bullet here, if you were to advise one of your clients, how they would get started with zero trust, how would they do that? The journey of a thousand miles starts with the first step, but I think the type of work that you do, John, where you're fixing authentication is really key to this, right?

John Bogdan: Yeah. We talked about the government's policies is you set a time where maybe new hires, that's the process they go through where when they submit their I-9 all their documentation, that's the indicators. Obviously, you have to go through some vet with your other employees at this point. Some of them may not have to go through the same rigor, but disseminating information to a corporate network is fairly simple.

Mike Engle: Well, there been a couple questions here, if anybody has them feel free to pop them into the chat, there's a couple questions about, "Well, what happens if I don't have a smartphone?" That is certainly something to consider. There's a couple options you can use modern browsers on laptops and workstations as well. That FIDO standard that we spoke about supports something called web authentication, WebAuthn.

That allows you to use the integrated biometrics as one option. There's some ways you can do that. You can also, of course, always fall back to legacy mechanisms you just have to make sure you have the right controls in place. Fight the authenticators, where you can plug them into USB or tap into NFC, et cetera. The other question that came up is how do you protect against fake driver's license and passports? It's a cat and mouse game, the bad guys get better and better at forging and attacking, et cetera.

Our document verification engine is updated pretty much every week, because it's doing a billion document proofs a month. We get a lot of samples. When a customer says, "Somebody came in and got a new Verizon phone with a fake ID." Then we'll figure out what that vector was and adjust the policy. There's about 600 different fraud checks that are being done on documents today. The documents are getting harder and harder. Real ID in the U.S. is making it harder.

The documents 20 years ago that I used to get into bars before I was 21 were super easy to copy and they're getting harder and harder cryptographic features and so forth, so we'll see. Then a couple other questions were answered already. I think we've about done it. Just check out our website 1Kosmos and click on the insights, which shows all the integrations and our developer portals there, which shows how you can basically click.

Try it online in real time and even download sample code at GitHub and do all this stuff in your dev development environment, whatever you want to do, all out there. No human interaction needed to start playing around with this stuff. Robert, did I miss anything? Have we done it?

Rob MacDonald: I was just looking to see if there was anything. Where's the biometric data being stored? Sorry, if I missed this in general, shouldn't we be avoiding biometric data in a central directory. That's a pretty good leading question, I think for your reply.

Mike Engle: It depends. The way we store data is with the user in charge of the private key using distributed technologies. 1Kosmos or our customers do not have access to the data, the end users control it. That is really, really important from a design principle. If the data's going into a traditional database and just encrypted, bad guys will get it eventually. Great question and something that needs to be understood before any system is used.

Rob MacDonald: Then, there was one that was already answered, but I think it'd be good for everybody to understand and it's a good one for both of you to talk about how does something like this fit into my environment? How do I get it to interact with Okta properly?

Mike Engle: John, please take that one. I think here with all the systems on the right, it's getting easier and easier to put something on the left.

John Bogdan: If you've ever integrated Okta to say a workforce to a [inaudible 00:44:31] or customer tenant, it's the same standards. It's the same process by setting up the IDP and the inbound SAML application. There's nothing unique when setting up the integration between Okta and 1Kosmos.

Mike Engle: Absolutely.

Rob MacDonald: Nice, easy answer, best kind. Any other? I think that covers it. There's a couple of other ones that we need to dig a little bit deeper into and I think it'd be better to write out the answer to a couple of those. For those of you that wrote some questions that we haven't answered yet, it's probably better we type that out. Outside of that, I think we got them all, guys.

Mike Engle: Very good. John, hanks so much for coming. Robert, thanks for bringing it together, Maria, guys. It was very good.

Rob MacDonald: Thank you very much. Thank you both for doing this. For those of you that want to hand it off, it has been recorded. We are going to post it on our website if you want to go back and watch it again, or you want to send it to some colleagues to go watch, it will be available on demand likely by the end of the day. Thank you. Thanks again for everybody joining and we'll see you again next month.